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ABSTRACT 



A common access method is disclosed to enable disparate 
pervasive computing devices to interact with centralized 
data management systenis. A modular, scalable data man- 
agement system is envisioned to further expand the role of 
the pervasive devices as direct participants in the data 
management system. This data management system has a 
pluraHty of data managers and is provided with a plurality of 
data managers in one or more layers of a layered architec- 
ture. The system performs with a data manager and with a 
input from a user or pervasive computing device via an API 
a plurality of process on data residing in heterogeneous data 
repositories of computer system including promotion, 
check-in, check-out, locking, library searching, setting and 
viewing process results, tracking aggregations, and manag- 
ing parts, releases and problem fix data under management 
control of a virtual control repository having one or more 
physical heterogeneous repositories. The system provides 
for storing, accessing, tracking data residing in said one or 
more data repositories managed by the virtual control 
repository. DMS applications executing directly within, on 
or behalf of, the pervasive computing device organize data 
using the PFVL paradigm. Configurable managers include a 
query control repository for existence of peer managers and 
provide logic switches to dynamically interact with peers. A 
control repository layer provides a common process inter- 
face across all managers. A command translator performs the 
appropriate mapping of generic control repository layer calls 
to the required ftinction for the underlying storage engine. 

18 Claims, 18 Drawing Sheets 
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r 



AUTHMGR CRI CALL: 



CRIFATGET USERA LOCK MOVE FILE 1 TYPE2 VARX ENTRY 

SELECT COUNT(*) FROM FILE_AUTHORITY WHERE 
USERID=USERA AND DOMAIND=LOCK AND 
NAME=MOVE AND FILENAME=FILE1 AND 
FILETYPE=TYPE2 AND VARIANCE=VARX AND 
LEVEL=ENTRY 



LOCKMGR CRI CALL: a^93 

CRILOCKSET USERA LOCK MOVE FILE1 rfPE2 VARX ENTRY "MODEL 
BUILD" 

UPDATE REFIDS SET U\STID=LASTiD+1 
WHERE TNAME=LOCKS V_g4 

SELECT USTID INTO REF FROM REFIDS 
WHERE TNAME=LOCKS V 



INSERT INTO LOCKS / 

(REF.DOMAIN,FILETYPE.VARIANCE,LEVEL,FILENAME. 
LOCKNAME.LOCKERID.DATEJIME.REASON) 
VALUES(REF,L0CK,TYPE2.VARX,ENTRY.FILE1.M0VE.USERA. 
1996052237.093921 /'MODEL BUILD") 
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METHODS FOR SHARED DATA 
MANAGEMENT IN A PERVASIVE 
COMPUTING ENVIRONMENT 

FIELD OF THE INVENTION: 

This invention is related to the management of disparate 
forms of data generated, captured, transmitted, or otherwise 
manipulated by pervasive computing devices, 

BACKGROUND OF THE INVENTION 

With all the advances in computer technology, virtually 
any machine, appliance or device is capable of generating or 
collecting vast amounts of data. Additionally, the growing 
trend towards global data sharing and electronic commerce 
is creating an environment where large quantities of dispar- 
ate data exist in a multitude of repositories each having 
non-uniform access methods. This typically requires data to 
be imported, exported, translated or even replicated among 
different data management systems. Consider an example 
hospital environment where all the data regarding a patient's 
care is managed by a large database like DB2. Despite the 
fact that these databases could serve as a single repository 
for all of the patient's hospital data, they don't. For example, 
if the patient is being monitored by a heart monitor, the 
output is usually strip-paper which may or may not wind up 
in the patient's "paper^' folder If a doctor wants to review 
the data sometime later, it's cumbersome and at times 
impossible to locate it. The patient's chart is another 
example of an important data object which is loosely man- 
aged. Every day several members of the hospital staff make 
updates in the chart, and it's usually done in written form on 
paper. Once again, accessing this data at a later time, 
especially by a doctor at a remote location, is cumbersome. 
Furthermore, one person may be updating the chart while 
another is trying to access it, unaware that updates are 
pending. Finally, diagnostic test results such as X-Rays, 
MRIs, CT-Scans, etc. all contribute to the pile of data 
compiled into the patient's folder. At some point all of this 
"paper" and "electronic" data must be referenced to calcu- 
late the patient's bill or analyzed by doctors to diagnose 
problems and prescribe treatment. Upon being discharged, if 
someone wanted to review all aspects of the patient's 
hospital stay (diagnostic tests run, test results, daily vital 
signs, doctor's exam notes, nurses charting notes, billing 
information, medication administered, etc.), it would 
undoubtedly require accessing several computer systems 
plus tracking down several files, papers, and other types of 
output media. 

In another example, a manufacturing company purchases 
raw materials or parts from vendors and assembles them, 
along with its own components, into finished products. 
These products are then marketed, distributed, and sold, 
possibly to other manufacturers for inclusion into their 
products. Although recent advances such as e-business and 
the world wide web have strengthened each link of the 
vendor-customer chain, the lack of a common organization 
method have impeded these businesses from sharing data 
between their computing devices. For instance, one vendor 
may be using a Windows NT environment for managing 
their product data. Their employees may use hand-held 
computing devices running Windows CE to remotely enter 
information into a Windows NT data management system. 
Because of the similarity in platforms and operating 
systems, these hand-held devices can successfully commu- 
nicate with the data management system. However, a prob- 
lem arises if a customer is using a Unix or S/390 system for 
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data management and wants to link it to the vendor's DM 
system. If the goal is to directly exchange data between the 
vendor's hand-held device and the customers Unix or S/390 
DM system, it may be imposesidle due to the incompatibility 

5 between the two platforms. 

Clearly the need exists for seamless management of data 
across all facets of the product development cycle, including 
data residing at different locations worldwide. Furthermore, 
as noted by Oliver Tegel in "Integrating human knowledge 
into the product development process" as published in the 
Proceedings of the ASME Database Symposium, Engineer- 
ing Data Management: Integrating the Engineering Enter- 
prise ASME Database Symposium 1994, ASCE, New York, 
N.Y., USA. p 93-100, specialists who are not working 

J 5 directly together are often needed for solving the demanding 
tasks that arise during the development of today's advanced 
products. During product development, assistance is 
required from other departments such as manufacturing, 
operations scheduling, etc. Even the vendors and customers 

2Q should be integrated into the product development process to 
guarantee the product developed will be accepted in the 
market. 

Another example, U.S. Pat. No. 5,201,047 to Maki et al. 
(issued Apr. 6, 1993) teaches an attribute based classification 

25 and retrieval system wherein it is uimecessary to implement 
an artificial code for indexing classifications. The patent 
teaches a method for defining unique, user-determined 
attributes for storing data which are capable of being readily 
augmented without necessitating the modification of the 

30 underlying query used for retrieval thereof. However, the 
Maki et al. patent requires that the data items being grouped 
share at least one common attribute to enable the grouping, 
and therefore fails to address the problems of managing data 
aggregates formed from disparate and unrelated data 

35 objects. 

Other data management systems address the creation of 
data aggregates coupled to particular processes implemented 
in the data system. For example, U.S. Pat. No. 5,321,605 to 
Chapman et al. (issued Jun. 14, 1994) teaches the creation of 

40 a Bill of Resources table which represents the resources 
consumed in the performance of a given process. Attribute 
tables for the given resources are utilized to determine 
whether additional processes which will consume some or 
all of the resources of a given process can be initiated. The 

45 patent to Chapman et al,, requires that each process to be 
initiated have a particular Bill of Resources aggregate asso- 
ciated therewith. This tightly coupled constmct does not 
permit the creation of data aggregates not related to a 
particular process implemented in the data management 

50 system. Furthermore, since a process must be contemplated 
in order to create a Bill of Resources table, Chapman et al. 
do not permit the creation of aggregates without foreknowl- 
edge of the process that requires the resource. Thus, in a 
manner similar to that described for Maki et al.. Chapman et 

55 al. require that a relationship between the elements exist 
prior to the formation of the Bill of Resources grouping. 

Also, unrelated DMS systems are known which are used 
for hardware implementations which enable related data in 
a computer memory, storage or I/O subsystem to be physi- 

60 cally grouped in proximity to other such data so as to 
improve hardware performance, application performance, 
and/or to solve memory management issues are known. For 
example, U.S. Pat. No. 5,418,949 to Suzuki (issued May 23, 
1995) teaches a file storage management system for a 

65 database which achieves a high level of clustering on a given 
page and teaches loading related data from a secondary 
storage unit at high speed. The patent uses map files includ- 
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ing a metamap file for defining page to page relations of U.S. patent application Sen No. 08/982,724 entitled 

data. These hardware implementatioos are not related to the "Modular, Scalable Data Management System", filed 

present invention, as they involve the managenaent of the Dec. 2, 1997, U.S. Pat. No. 5,966,707. 

physical contents of a data object rather than the manage- All teach various methods employing a modular scalable 

ment of aggregations of data objects as we perform the 5 data management system which is also envisioned as part of 

methods of our present invention. It is contemplated, the present invention. However, these inventions and appli- 

however, that such known hardware techniques may be cations assume all the data being managed already exists on 

implemented in a system comprising the aggregation man- ^ traditional computer machine comprising one or more 

agement features disclosed herein, thereby further augment- processors, memory and I/O devices for a user to interact 

mg the overaU system efficiency. . , . 10 with such as a keyboard, mouse, display, microphone, etc. 

During our development process we have viewed the ^ ^^^^^ demonstrating how the underlying prin- 

development of others. Even the best of the EDA (electronic ^. ^ ^^ ^^^^^ ^^^^^^ non-traditional computers 

design automation) design houses don t have an integrated ^, j- 1 j- * • j * • i u * 

approach like we have developed. ^^"^^ f , f^'^^^^ diagnostic equipment, mdustrial robots 

\^ , r.L- i_ 1 , Ml J- hand-held devices, etc. which can be made to interact with 

For the purposes 01 this background, we will discuss some , , , . , , , • t 4 j * 

of the various approaches already used specifically viewing said data management system to assmiilate data manage- 

them in light of our own separate developments which we "^^^j f ^''^""^^y "^^o Ibeu- primary tasks without the 

will further elaborate in our detailed description of our h^man intervenUon. 

invention which follows later in this specification. Mother growing problem involving pervasive compuUng 
In the field of EDA, there are today several leading edge ^^^^^^^^ ^he ability to disseminate data from a central server 
providers of Data Management technology. Among them are to a plurality of remote computing devices, and maintam 
Cadence Design Systems, Inc., ViewLogic Inc., and Syn- synchronized copies of the data at all locations. Lotus Notes 
chronicily Inc., Of course there are others, but these the (a trademark of Lotus Development Corporation, a subsid- 
companies that have the capability to provide complete data iary of International Business Machines Corporation) and 
management solutions that encompass all facets of the the Briefcase (of Microsoft Corporation) application within 
business process including design, manufacturing, quality 25 Microsoft's Windows 95 operating system are examples of 
control, defect tracking, project management and the like. application software which seeks to synchronize data 
However, review of their most recent technology still affords between remote and host computers. Lotus Notes incorpo- 
the opportunity to make improvements in the area of rates a sophisticated process known as replication to achieve 
scalability, modularity and adaptation of disparate environ- this goal. During replication, the data within a client com- 
ments into a seamless Data Management enterprise. 30 puter's database is compared against the data on the host 
Historically many attempts have been made to manage server and the computer with the oldest copy is updated with 
and share data across groups of users or teams, lliis has the most recent. Upon completion of replication a complete 
typically resulted in systems that assume a particular use image of all the data resides on both machines, 
model and expect the users to mold their process or meth- If the database undergoing replication is large a disad- 
odology around it. Furthermore, these systems tend to either 35 vantage of this method becomes apparent; an equivalent 
be a closed architecture which is difficult to enhance or amount of storage space is required on the client computer, 
customize. In addition these systems can be large and even if the user only intends to access a subset of the data, 
complex, and lacking the ability to scale from a small team Notes does permit data to be organized in FOLDERS, which 
of "low-end" users to a large group of sophisticated "high- can be selectively included or excluded from replication, but 
end" users. U.S. Pat. No. 5,812,130, entitled "Data Man- 40 this fails to address the problem when the user needs to 
agement System and Method for Concurrent Engineering", access small amounts of data from the majority of the 
and U.S. Pat. No. 5,826,265 entitled "Data Management folders. The problem compounds for large data management 
System Having Shared Libraries*', both issued to Van Huben environments with tens or hundreds of people trying to share 
et al, as well as the following patent applications: data residing in one database. These limitations make it 
U.S. patent application Sen No. 08/772,064 entitled "Data 45 difficult to centralize the management of different types of 
Management System for Concurrent Engineering*', filed data as well as inhibit the interaction between several 
Dec. 6, 1996, now abandoned. disparate pervasive devices. 
U.S. patent appfication Sen No. 08/761,474 entitled "Data Another problem with the aforementioned synchroniza- 
Management System for Problems, Releases and Parts", tion methods is the requirement that all clients must be 
filed Dec. 6, 1996, U.S. Pat. No. 5,864,875. 50 capable of executing a local copy of the synchronization 
U.S. patent application Sen No. 08/761,253 entitled "Data application (such as Lotus Notes). Devices such as a digital 
Management System and Process", filed Dec. 6, 1996, camera generate data can be useful in a Lotus Notes 
U.S. Pat. No. 5,878,408. environment, but in order to assimilate it into that environ- 
U.S. patent application Sen No. 08/760,913 entitled "Data ment the camera necessitates a link to a personal computer 
Management System for File and Database 55 executing a client copy of Lotus Notes. This not only 
Management", filed Dec. 6, 1996, U.S. Pat. No. 6,088, requires a hardware platform with significant resources (i.e. 
693. Pentium-class PC, 32 MB RAM, minimum 200 MB Hard 
U.S. patent application Sen No. 08/761,463 entitled "Data Disk), but it must be a true "computer" (PC, Workstation, 
Management Control System for File and Database", filed Server, Laptop, etc.) running a full size operating system 
Dec. 6, 1996, U.S. Pat. No. 5,920,873. 60 (Windows NT, Windows 95, OS/2, OS/390, etc.). This 
U.S. patent application Sen No. 08/762,236 entitled "Data virtually alienates small pervasive devices such as cell 
Management System Having Data Management phones, pagers, PDAs, electronic organizers, etc. Since 
Configuration", filed Dec. 6, 1996, U.S. Pat. No. 5,920, Notes is capable of managing a multitude of information 
867. including e-mail, addresses, telephone numbers, 
U.S. patent application Sen No. 08/759,692 entitled "Data 65 appointments, etc., one can envision how productivity can 
Management Control System for CD A Applications", be improved by enabling a direct exchange of information 
tiled Dec. 6, 1996, and U.S. Pat. No. 5,950,201. between pervasive devices and such an application. 
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FIG. 2 shows an overview of the preferred embodiment 
through the use of an architectural block diagram. 

FIG. 3 A shows a symbolic representation of the PFVL 
PARADIGM for both a single Package and a grouping of 
hierarchical Packages. 

HG. 3B shows how the PFVL PARADIGM can be 
adapted to multiple real life applications. 

FIGS. 4A and 4B depict a complex Data Repository 
illustrating various means in which data can physically 
reside in the Data Management System. 

FIG. 5 shows a detailed diagram of the DMS Application 
Layer introduced in FIG. 2. 

FIG. 6 depicts the detailed operation of the Command 
Translators introduced in FIG, 2. 

FIG. 7 describes the detailed architecture of the Client/ 
Server Interface layer. 

FIG. 8 shows an example of how a DMS function is 
invoked with the standard API and is transferred through the 
architecture to the Control Repository Access layer. 

FIG. 9 shows examples of Control Repository Access 
transactions 

HGS. lOA. lOB & IOC illustrates the present invention 
by way of an example 

FIGS, llA & IIB illustrates the present invention by way 
of an example manufacturing environment. 

FIGS. 12A, 12B & 12c depict a remote or mobile 
computing environment employing various features of the 
present invention, manufacturing environment. 
(Note: For convenience of illustration, FIGURES may be 
separated in parts and as a convention we place the top of the 
FIGURE as the first sheet, with subsequent sheets proceed- 
ing down and across when viewing the FIGURE, in the 
event that multiple sheets are used.) 

Our detailed description explains the preferred embodi- 
ments of our invention, together with advantages and 
features, by way of example with reference to the afore- 
mentioned drawings. 

DETAILED DESCRIPTION OF THE 
INVERIION 

The present invention employs the use of a modular, 
scalable Data Management System (DMS) combined with a 
universally applicable organizational paradigm which 
enables a plurality of disparate pervasive computing devices 
to interact with said Data Management System using uni- 
form access methods. Both the access methods and the 
underlying DMS can be implemented using various means, 
and although our invention is illustrated using specific 
embodiments, it should be noted that the invention is by no 
means limited to the scope of these scenarios. 

FIG. 1 depicts the overall architecture of the invention 
whereby a multitude of pervasive computing devices (10) 
such as palmtop computers, pagers, electronic organizers, 
industrial robots (11), servers (12), workstations, terminals, 
peripheral devices such as digital cameras (13), bar code 
scanners (14), personal computers (15), medical diagnostic 
and imaging equipment (16) and portable computers (17) 
such as notebook and laptop computers interact with a 
Central Repository (18). Our invention conveys a common 
access method that can easily be implemented in these 
devices and apparatus as long as they support any type of 
communication protocol capable of transferring data 
streams to the Central Repository (18) either via direct 
connection or indirectly such as using uploading the data to 
a personal computer, and then establishing a connection 
from said personal computer to the Central Repository (18). 
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Our invention contemplates several means of implemen- 
tation for the Central Repository (18). The preferred 
embodiment will demonstrate how the underlying Data 
Management System can be comprised of relational 

5 databases, object oriented databases, file systems, metadata, 
file formatted tables or any other means which enables data 
to be organized and accessed. Additionally the Central 
Repository (18) can physically reside across a plurahty of 
disparate systems including, but not limited to, servers, 

10 mainframes, workstations, personal computers, portable 
computers or any other device that constitutes a machine 
enviroimient capable of executing a program of instructions. 

The pervasive computing and peripheral devices (10 
through 17) shown in FIG. 1 establish communication links 

15 either directly or indirectly to the Central Repository using 
any applicable communication protocol such as, but not 
limited to, TCP/IP, RS-232, Bisync, wireless, infrared, etc. 
which can be tised to transmit transactions based on an 
access method that permits each device to interact with the 

20 repository in a common fashion regardless of the commu- 
nication protocol used or the repository implementation. 

y^N, In order to further understand the preferred embodiment, 

\^we find it beneficial to describe the underlying architectural 
principles disclosed in U.S. patent application Ser. No. 

25 08/982,724 entitled Modular, Scalable, Data Management 
System. The present invention contemplates the use of said 
Modular, Scalable DMS employing a novel, layered archi- 
tecture which permits the DMS to be constructed and 
maintained in a modular fashion. Additionally, this approach 

30 also allows the DMS to be easily scaled fi'om a low-end 
client-only system to a large, high-end globally distributed 
enterprise wide data management system. In accordance 
with our preferred embodiment a Data Management System 
has a plurality of data managers and is provided with a 

35 plurahty of data managers in one or more layers of a layered 
architecture. The j^y^t^rr] performs with a data manager and 
wjt b^a user inpu t v ia an API a p lurality of p rocess on da ta 
residing in heterogeneous datare positories of said comjMiter 
s\^tem iniclu dmg: promotion. ch £ck=in ,_check-out, lockin g, 

40 hbra^seaSE£g>-S£ ttinfi and view ing pro cess resu lts, track- 
ing ag gregations, andma naging p^s , releases anH'pfSbTem 
fi?^ta under. manageme"nr CO nfroi of a virmal contro l 
repository having one or more physical Heterogeneous 
repositories. The system provides for storing, accessing, 

45 tracking data residing in said one or more data repositories 
manag ed by the virtual control repository. User Interfaces 
provide a combination of command hne, scripts, GUI, 
Menu, WebBrowser maps of the user's view to a PFVL 
paradigm. Configurable Managers include a query control 

50 repository for existence of peer managers and provide logic 
switches to dynamically interact with peers. A control 
repository layer provides a common process interface across 
all managers data view maps to a relational table paradigm 
and maps control repository layer (CRL) calls to sequences 

55 of SQL queries. A command translator for a relations data 
base provides pass through of SQL queries. Table files map 
SQL Queries into a set of FILE l/0*s with appropriate inter 
I/O processing, and meta data maps SQL Queries into Meta 
data API calls with appropriate inter I/O processing. DMS 

60 functions and utilities include an API, and a a complete set 
of functions based on a PFVL paradigm. PFVL paradigm 
calls are mapped into DataManager(s)/Control Repository 
calls. The client/server interface is a common interface to a 
enterprise Client/Server network, and may be reduced in size 

65 for acting for a co-resident client/server. The data repository 
is an aggregation of disparate data storage engines. A 
package manager tailors the control repository and provides 
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Although this example cites Lotus Notes, one skilled in limited to, health care equipment (CT-Scanners, Magnetic 

the art can appreciate how this problem grows in complexity Resonance Images, cardiac monitors, laboratory test results, 

when one considers the task of integrating all the various etc.), industrial robots, bar code scanners, digital cameras, 

types of pervasive devices with the myriad of computer palm top computers, laptop computers, pagers, electronic 
platforms, operating systems, databases, data management 5 organizers, audio dictation and recording equipment, and 

systems, and protocols in existence. musical equipment. These devices, or any other pervasive 

devices employing a programmable machine such as an 

SUMMARY OF THE INVENTION embedded controller, microprocessor or digital signal 

^ , • L J J processor, locally execute a DMS application which gathers 

In accordance with our invention we have provided a ■ j j / a * * * v a t\.*^ 
. , . ... . 1 J . : , . 10 the required data and transmits it to the centraUzed Data 

method for enabhng a central data management system to System using a variety of communication 

interact with a pervasive computmg device, comprismg the J p8 ^ ^ 

steps of providing a common access pro toco for enabhng P » ^ 

any pervasive computing device capable of executing a J establishing a connection between a 

control program tangibly embodying a program of instruc- P^^,^.^^^^ ^^^^^^^^ transferring digital 

tions to interact with a centralized data management system, ^^^^ streams ^ o 
and providing a commonly accessible data management 

system which possesses a pluraUtyofdata managers for data The data management system described herem has a 

residing in a data repository managed by a virtual control plurality of data managers and is provided with a plurality of 

repository ^^'^ managers in one or more layers of a layered architec- 

„ .* J • * A ture. The system performs with a data manager and with a 

Pervasive computing devices m accordance with our • / • Am i i-* * a ^ 

... ^ *u J u- u •* user input via an API a plurality of processes on data 

invention utihze a common access method which permits j- • l u * j . •* * 

- . J . . . J u • 1 1 * residmg in homogenous or heterogeneous data repositories 

the disparate data to be managed by a single virtual Data c -f . * • i j- *• u i • 

^ *c.* u A ii 1U1 u* of said computer system includmg promotion, check-in. 

Management System based on a modular, scalable architec- , , , , a • - 

%, -J* *u pj** i check-out, locking, library searching, settmg and viewing 

ture. The pervasive devises are those found in typical w . i • .- a • * 

^ , ^ . . i fr^^ process results, tracking aggregations, and managing parts, 

corporate and enterpnsc envuonments where elements of *^ , a a a. a — ♦ * i ^ 

.t. . XM .o* u releases and problem fix data under management control of 

the Data Management System may exist on a homogenous i . i u • u • i 

computer platform or they may be dispersed among a * repository havmg one or more physical 

plurahty of platforms in a distributed computing envi^n- heterogeneous repos.tones. Tie system provides for ston^^^ 

. ' \ *i. ' A ' A accessmg, tracking data residing in said one or more data 

ment. The interaction between these pervasive devices and T j u *u i » i 

. * 1- u J *i- I. repositones managed by the virtual control repository, 

the Data Management System is accomphshed through a *^ & / t j 

plurahty of commonly available communication protocols Our invention further provides a means for data generated 

which permit the Data Management System to be particu- or captured by pervasive devices to be stored temporarily or 

larly useful for business solutions which employ our pro- permanently on said devices, and whereby these devices can 
cesses and methods, such as health care, manufacturing, -5 become extensions of the central repository. For example, 

electronic business (e-business or e-commerce are images from a CT-Scan can be stored in a locally attached 

synonymous) and commerce, inventory tracking, distribu- disk file and organized by PFVL. This permits the Control 

tion and any related field which can benefit from a common Repository, which may be a DB/2 relational database run- 

repository for managing data from a variety of sources, °"ig 0° ^ server, to access and manage this data. This is 

^ . ^. . . *u J u' u accomplished without the need for the pervasive device to 

Our invention provides a common access method which 40 T^n/o i_ .t_ * ^ . 1 

. . ^ ^ . J • . • * * run a copy of DB/2 or even be aware that the Control 

permits almost any pervasive computmg device to interact „ • • 1 * j **l ic * 1 

, .^rx , *o * /¥^»jfo\ * Repository is implemented with DB/2. If the Control 

with a centrahzed Data Management System (DMS). Data „ . . . .1 ^ 

, J ^ , • 1 T J *1 • * A Repository changes to another unplementation, such as an 

generated, captured, manipulated, or otherwise transmitted ^ , , , . r..»*« i- .i 

by these pervLve computing devices is stored in the DMS ^'^"^^ apphcalions withm the pervasive 

using the PFVL PARADIGM as a means of organizing 45 °° 

disparate data in a similar and consistent manner. Additionally the present invention demonstrates several 

Furthermore, the DMS is implemented using a modular, improvements in the area of data access, sharing and syn- 

scalable architecture which permits maximum flexibility chronization among multiple disparate pervasive or tradi- 

ranging from a homogenous DMS whereby all data is tional computmg devices. These methods can be used to 
managed by a single physical entity all the way to a 50 facilitate e-business, increase remote computing efficiency, 

heterogeneous environment comprised of a plurality of automate many data management tasks traditionally 

entities. For example, the Control Repository which tracks performed via manual data entry or omitted entirely. Our 

the actual data objects and their attributes can be realized invention further demonstrates how the concepts conveyed 

using relational or object oriented databases, metadata, flat ^ the disclosure can be applied to virtually any data reposi- 
file tables, directory structures, or binary encoded control 55 '^^y including groupware such as Lotus Notes. The under- 

files. The underlying DMS applications can be implemented ^V^Z Control Repository Ubles can be implemented using 

using any typical programming or macro language, includ- databases, document, and even spreadsheets, 

ing but not limited to, C, C++, Java, Basic, Assembler, Perl, These and other improvements are set forth in the fol- 

Unix Shells, JES, Lotus Script, SQL, REXX, etc. This lowing detailed description. For a better understanding of 
permits the same methods to be incorporated across dispar- eo the invention with advantages and feaUires, refer to the 

ate repositories and pervasive devices. description and to the drawings. 

The system we employ uses a data management control DESCRIPnON OF THE DRAWINGS. 

program tangibly embodymg a program of mstructions 

executable by a supporting machine environment for per- FIG. 1 shows an overview of the preferred embodiment 
forming method steps by a data management system having 65 illustrating a plurality of disparate pervasive computing 

a library organization which receives a request initiated firom devices interacting with a centralized Data Management 

one or more pervasive computing devices such as, but not System. 
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methodology customization with package, variance, tories separately. The Data Repository may be implemented 

file type, level granularity. using a plurality of means ranging from simple file systems 

Generally, by reviewing this invention, as well as the prior to commercially available Product Data Management 

application it will be appreciated that we provide as (PDM) systems such as RCS, Sherpa, MetaPhase, etc. The 
described herein a modular, scalable Data Management 5 data can be physically located in a sin gle storage m edium 

System which uses a single paradigm to manage similar or such as a hard disk, local file system, or server, or distributed 

disparate data objects in a local or distributed client/server throughout a plethora ofstorage^ediascattered geographi- 

environment. llie modular implementation method dis- cally. The^centralizcdContr ^ Repository c an bc^ imple- 

closed herein affords the opportunity to install, implement or mented tisSgsiverarapplWac^^ including biTt not~ limited 
configure new elements to the system as the demand lo to, relational or object oriented databases, flat files, meta 

changes. Furthermore, the scalable nature of our system and data files or ta ble formatted files . This disclosure describes 

methods permits the same DMS to grow from a simple, the use of Commana I'ranslators "which map ^enepc Contro l 

low-end client-only environment to a high-end fully secure Repository Ir ^actions lo the appropriate a ccess method 

client-server implementation. The improvements which we cdFreSprmtHn ^o the ptiysical im plementation. This 
have made demonstrate how a single data management 15 approactr-pcnims tne information in the Control Repository 

architecture can be used to adapt to virtually any method- to be migrated between different physical implementations, 

ology or process. Our processes thus provide a framework It even allows multiple physical implementations to act as a 

for accommodating a plurality of physical storage reposito- single logical Control Repository. 

ries in addition to a centralized Control Repository which We will describe in the following detailed our new 

can be implemented using various means. 20 processes and methods with respect to the overall architec- 

Generally we proceed by employing a layered architec- ture with advantages and- features next with reference to the 

ture centered around a plurality of MANAGERS conform- drawmgs. ^ 

ing to a common data classification method known as the ^ r^^rr^n at t Any^iTiTr^z-^TnT- 

nm/T rkAnxrvTOK* Tn.- « 11 J . /V^l OVERALL ARCHITECTURE 

PFVL PARADIGM. This flexible paradigm allows data (\V I 

related to hardware design, software development, inventory 25 V FIG. 2 depicts the overall architecture of the preferred 

control, manufacturing or any other field requiring shared embodiment. The entire DMS architecture is based on the 

data management to be tracked using the same Data Man- PFVL paradigm, illustrated in FIG. 3, which allows the 

agement System. All objects are tracked with a centralized DMS to be environment and methodology independent. All 

Control Repository and stored in a shared Data Repository. interfaces into the DMS use a standard PFVL based API 

We use our Managers and architectural layers as a frame- which provides the flexibility to use a common DMS across 

work for a plurality of applications, functions and transac- several similar or disparate user groups. For example, this 

tioas implemented in a modular fashion. Smaller transac- system could be used to manage the data for both the 

tions and functions can be combined to form larger more electrical and mechamcal components in an automobile 

complex functions or data management applications. This company. 

layered implementation promotes the concept of functions In order lo understand many of the underlying architec- 

and transactions which can be instantiated in a plurality of tural concepts conveyed in this disclosure, we turn our 

applications. The layers also permit applications to be writ- attention to the PFVL diagram depicted in FIG. 3. FIG. 3A 

ten without explicit knowledge of the physical implemen- illustrates the PFVL PARADIGM through the use of a 

tation of the Data Management System. multidimensional symbol such as a cube. The present inven- 

Adaptation of the DMS to a user environment is accom- tion teaches the notion that all objects resides in a Data 

plished through a single architectural layer, lliis allows the Management System can be classified according to five 

architectural core, including all the transactions and func- h^^c attributes: 

tions encompassed therein to remain methodology and envi- PACKAGE An arbitrary grouping of data objects that has 
ronmentally independent. some relationship, or common bond with each other. 

Our DMS allows applications to remain methodology ^^^^ package contains one or more variances, 

independent through the use of a standardized application VARLWCE One or more objects within a package that, 
program interface. User interfaces can be constructed to when combined with the remaining objects in the same 

customize the same DMS application several different ways Variance or from one or more dependent Vaiiances, 

to conform to user methodologies. Conversely, our invention comprise a coherent and meaningful collection of 

teaches an alternative method for implementing applications objects. 

using easily customizable state tables. LEVEL A collection of objects, within a Variance, that 

Our Client/Server Interface allows the elements of the have achieved some arbitrary degree of quality. 

DMS to interact locally in a client-only environment or via FILETYPE A collection of objects sharing the same data 
a client/server connection. TTie client/server implementation 55 type or format, 
can be achieved in a Local Area Network, Wide Area VERSION An iteration of a data object 
Network or a globally distributed environment such as the As an example, FIG. 3A depicts PACKAGE "A" (30) 

internet. comprised of two Variances. Within each VARIANCE are 

Scalability of the DMS is achieved through the use of one or more data objects (31) of a given FILETYPE, 
configurable Managers which can be switched on or off 60 residing at one or more LEVELS, with one or more VER- 

depending on the needs of the users. Since all the Managers SIONS of the object. In the simplest case, a single Version 

conform to the PFVL Paradigm and follow a standardized of a single Filetype exists at a single Level within a single 

application program interface, new Managers can be added Variance of a single Package. Our invention achieves tre- 

to the system without the need to reconstruct or alter the mendous flexibility by allowing any of these attributes to be 
existing DMS. 65 expanded N ways. By varying the dimensions of the cube. 

The physical implementation of the DMS is described in and the number of cubes in the Package, one can create a 

1 ^ / two sections which deal with the Data and Control Reposi- DMS capable of managing data in almost any environment. 
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The present invention also permits Packages to be 
arranged hierarchically. This is illustrated at the bottom of 
FIG. 3 A where Package "A" (30) is embedded within a 
higher level Package (32). The higher level Package may 
also contain its own data objects (31) as shown in the figure. 5 
This is possible because each Package in the hierarchy has 
its own set of PFVL attributes. For example, a printed circuit 
board could be considered a high level Package comprised 
of various ASICs, resistors, capacitors and connectors. The 
ASICs on the board could be considered .Packages lO 
themselves, where each ASIC Package is comprised of the 
underlying circuit designs. 

FIG. 3B contemplates two examples of how the PFVL 
Paradigm can be implemented in actual applications. The 
first table (33) demonstrates a typical electrical engineering 15 
design environment comprised of design objects dispersed 
in the DMS, The primary design object is an MPEG design 
consisting of multiple versions of a schematic residing in the 
"dsgn_„lib" design library. Tliis library also contains a 
VHDL object for the MPEG design. It can also be seen that 20 
the dsgn„lib library contains two Levels, Test and Prod. 
Versions of the MPEG schematic simultaneously exist at 
both Levels. Most of the objects are classified under the 
Universal Serial Bus (USB) Variance, except for a PCI 
Variant of the MPEG schematic. Our invention allows 25 
Variances to be completely independent or dependent upon 
other Variances. In this example, if the PCI Variance is based 
on the USB Variance, then all objects in the USB Variance 
can be picked up and used in the PCI Variance, unless they 
need to be modified. DMS Table 23 also illustrates an 30 
additional object, the Bus Controller, which also resides in 
the PCI Variance of the dsgn_lib library. Finally, the dia- 
gram illustrates an MPEG Layout which resides in a sepa- 
rate Package known as the Circuits library. 

The second DMS Table (34) in FIG. 3B shows how the 35 
same PE^L paradigm can be used to track objects and 
subassemblies in an automotive environment. In this case, 
Packages are used to denote the Cooling and Engine sub- 
assemblies as well as the Electro-Mechanical main assem- 
bly. Within each sub-assembly are one or more components 40 
described in the form of schematics, layouts and VHDL, and 
residing at quality levels QAl, and QA2. Also, some com- 
ponents exist under distinct Variances in order to accom- 
modate two different automobile models. 

Returning to the overall architectural diagram identified 45 
as FIG, 2, the top layer is the USER INTERFACE LAYER 
(20). This layer makes possible such scenarios as sharing 
electrical and mechanical design information by acting as an 
environmental adapter. An example of such an adaptation is 
present in a large electronic design organization where 50 
several design groups need to share data among several 
libraries. A common DMS application in this scenario would 
be a Check-In operation which allows data to enter the DMS 
from a user's private work space. Since the DMS accom- 
modates several design groups using numerous libraries, the 55 
DMS Check-In application's API requires one of the invo- 
cation parameters to be the PACKAGE. If the methodology 
requires all the designers on a team to check their data into 
a single library, the User Interface Layer may employ a local 
"wrapper** or user utility which only requires the user to 60 
enter the name and type of design object being checked in. 
This wrapper then passes this information to the DMS 
Check-In application. It also supplies the sole library name 
as the PACKAGE as well as a hard-coded LEVEL and 
VARIANCE. 65 

To further demonstrate the advantage of the User Inter- 
face Layer, consider a second design group which also uses 
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the same DMS to manage their data. Unlike the first design 
team, this one designs subassemblies in which each sub- 
assembly is treated as a PACKAGE. Since this team requires 
access to multiple packages, their Check-In function may 
consist of a "wrapper" in the User Interface Layer which 
invokes a menu that permits the user to specify a Sub- 
Assembly name. The wrapper then calls the same DMS 
Check-In application used by the aforementioned design 
group. However, this wrapper passes the Sub-Assembly 
name as the PACKAGE rather than hard-coding it like the 
first wrapper. 

One skilled in the art could easily envision how the User 
Interface Layer can employ several methods such as, but not 
restricted to, wrappers, shell scripts, batch files, command 
fine interfaces, graphical user interfaces, web browsers, 
menus, or voice activated systems, which would be custom- 
ized to the user's environment or methodology. The advan- 
tage to this approach is it allows different methodologies or 
processes to utilize the same underlying Data Management 
System. In addition, if an existing methodology changes, the 
underlying DMS fimctions remain intact. Only the functions 
in the User Interface Layer need to be modified to accom- 
modate the new methodology. 

Returning to FIG. 2, our preferred embodiment contem- "\ 
plates the use of several layers which comprise the core 
architecture of the DMS. Spanning three of the layers are the 
DMS MANAGERS (21). These are comprised of a plurality 
of functions, some of which belong to the DMS Apphcation, 
Client/Server and Control Repo sitory Access la yers. By 
grouping these functions^to isolated Managers^th stan- 
dardized interfaces, a great deal of modularity is achieved. 
Furthermore, these functions can be combined to form 
larger, more complex, applications. Consider the following 
portion of an example promotion application which illus- ' 
trates one way to deploy a modular DMS: 

if (Lock__Manager_Installed) { 

query Control Repository for any locks that exist on the 
file 

if (locks_exist) fail the promote 

} 

if (Authority _Manager Installed) { 

query Control Repository to see if user has authority to 

do the promote 
if (user_not_authori2ed) fail the promote. 

} 

if (Process_Manager_Installed) { 

query Control Repository to see if any Library Pro- 
cesses need to run 

if (library processes_exist) invoke them and wait for ' 

completion 

Check Promotion Criteria 

Tell Control Repository to update level of the file 

Perform necessary update to data repository (move file, 
update link, etc.) 

Within each code branch one or more Manager functions 
are invoked to perform the necessary DMS operations. By 
combining these functions together in an algorithmic way, 
one can achieve highly complex DMS appHcations. 
Furthermore, one can see how modularity can be achieved 
using the IF statements to test the Control Repository for 
existence of a particular Manager. This permits Managers to 
be installed or configured in a "plug-n-play" manner simply 
by setting switches in the Control Repository, 

One could also envision an alternate embodiment where 
all the functions within each manager are compiled into 



12/09/2002, EAST Version: 1.03.0007 



us 6,327,594 Bl 

13 14 

independent objects. A DMS vendor or supplier could then storage engines or PDM products such as RCS, Sheqia, 

construct customized DM systems based on the customer's MetaPhase, SCCS, CMVC, and ClearCase. Furthermore, the 

needs, simply by linking together the required modules. For present invention permits Automated Library Machines to 

example, customer A may only require basic data manage- be employed as Data Repositories. As shown in FIG. 2, all 

ment services so the DMS provider would only link the 5 communication with the Data Repository is performed 

object code from the Library, Package and Lock Managers through the Qient/Server Interface layer, which permits the 

into a "lite" version of the DMS. Customer B, on the other ^^^^ Repository to be locally accessible to the cUent, or 

hand, may require use of appHcations involving aggrega- distributed anywhere in the global enterprise on a remotely 

tions (configurations) and Library Processing. This custom- accessible server. , ^ , „ • a c 

er's DMS would link the object code from the Library, lO FIG- 4 depicts a ^mplex Data Rep^^^^^ 

„ , T 1 A jr. »x J Data Repository A (40) which is a simple UNIX directory 

Package Lx)ck Aggregation and Process Managers Regard- ^^^^^ ^^^^ ^^^^ ^ ^^^^^ Additional data may 

less of the miplementation method one skilled in the art can stored inDMaRe2QsitQaBi41) which is a commerciaUy 

clearly envision the advantages afforded by such a system a'^^SIIaHe'PDi^SSh^ Sherpa. Although these 

smce enhancements or changes to functions m one Manager ^^^^^^^^ £^^^^£5 automatically handle revision control when- 

donU require the entue DMS to be recompiled, or redistrib- 15 ever a user checks data into or out of the system, the 

^ted. preferred embodiment maintains it's own unique file iden- 

FIG. 2 also depicts the DMS APPLICAHONS layer (22) tifier in the form of a File Reference number within the 
which contains all the standard utilities that a user needs in Control Repository, The main reason for this is that it allows 
order to interact with the DMS. This includes things like all data in the DMS to be tracked in a similar fashion 
Check-In, Check-Out, Promotion, Locking, Library 20 regardless of the physical storage method employed. 
Searching, creating and tracking an aggregation or Furthermore, if the data ever needs to be transplanted from 
configuration, and setting or viewing process results. These one storage engine to a completely different one, the opera- 
utilities are described further is this disclosure as either tion can be accomplished by checking the data out of the old 
functions residing within a particular Manager, or applica- storage engine, checking it into the new one, and updating 
tions which consist of one or more functions, confined to a 25 the associated Control Repository table which maps the File 
single Manager or involving a plurality of Managers. All Reference number into a revision number. Since all infor- 
functions and applications within this layer follow a mation associated with the object is tracked by PFVL and 
consistent, standardized Application Program Interface File Reference number, the information is kept completely 
which allows them to remain isolated from any user envi- in tact even if the old and new storage engines use com- 
ronment or methodology, lliis feature of the invention 30 pletely different revision control methods. Returning to FIG. 
allows a single DMS to be deployed through several user 4, Data Repository C (42) could be a physical location on a 
groups performing similar or disparate work, yet having the server accessible via a Universal Resource Locator (URL) 
need to share data between them. on the World Wide Web (WWW). Although all data in this 

In the preferred embodiment, all functions and apphca- system is stored using a variety of means, the PFVL Para- 

tions communicate with the Control and Data Repositories 35 digm serves as the common storage model such that any 

through the CLIENT/SERVER INTERFACE (23) layer. client (43) can interact with the data. Furthermore, data is 

This is an expandable or contractible layer designed to allow directed to the appropriate Data Repository through the use 

either communication between the various layers in a client- of the Data Repository Table (44). It clearly illustrates how 

only environment or between clients and one or more the PFVL attributes can be used in any combination to 

servers existing anywhere in a global enterprise. The same 40 segregate the data into one or more physical repositories. For 

set of Manager functions, DMS applications and Control example, all VHDL in the MPEG design library will be 

Repository Access routines are utilized regardless of the stored in Repository B which represents one of the com- 

client/server topology. mercial revision control engines such as RCS or Sherpa. 

All communication into the Client/Server interface layer 1 Wiring Layouts for the Rel__l Level of the Base Variant of 

is directed to either the CONTROL REPOSITORY 45 the MPEG design library are stored in a DFS directory 

ACCESS LAYER (24) or the DATA REPOSITORY (25). represented by Repository A, and customer documentation 

The Control Repository Access Layer consists of one or j for the MPEG desig n is stored in a publi cly accessible URL 

more "transactions'* which perform simple or complex I represented by Repository C. 

operations against the Control Repository (CR) itself. These / One skilled in the art will also note that the use of wild 
can typically be categorized as adding information to the/ 50 cards in conjunction with the PFVL attributes permits a great 
CR, modifying existing information in the CR, deleting \ deal of granularity in storage partitioning. ITie example 
information from the CR, or extracting (and potentially 
filtering) information out of the CR. Regardless of the type 
of operation, all transactions in this layer are written as if the 
Control ReposiTory is a single virtual repository consisting 
ofj ahles organized around th e- PFVL pa radigm. This 
approach allows different physical implementations of the 
Control Repository. It even permits a plurality of physically 
different implementations to appear as a single virtual Con- 
trol Repository. 



shows a wild card (*) in the Filename field, but this could 
also be filled in with a specific file or a family of files 
matching a certain pattern. Additional fields could also be 
added to the table such as a Version field to allow data to be 
physically segregated by version or File Reference numbers, 
or number patterns. This approach offers the advantage of 
being able to not only use different storage methods for 
different types of data, but also solves problems associated 
60 with large, incompressible, files filling up physical storage 
Our invention further contemplates a virmal DATA media. This problem is prevalent in many commercial 
REPOSITORY (25) comprised of one or more physical available data management systems which require either 
repositories. The underlying repositories can be a simple file entire libraries or entire releases of data to be physically 
management system such as the Distributed File System stored using the same means under a common directory 
(DFS) or a simple directory stmcture organized on a hard or 65 structure. 

floppy disk. Correspondingly, the data repository coidd be Returning to FIG. 2, the bottom of the diagram shows the 
consUiicted using proprietary or commercially available \ CONTROL REPOSITORY (27) which can be implemented 
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using a multitude of methods, including, but not limited to, 
Table Formatted Files, Relational or Object Oriented 
Databases, Lotus Notes databases, spreadsheets, or Meta- 
Data files in any format. Our invention also permits one or 
more of the above implementations to be used simulta- 
neously to comprise a single virtual Control Repository. 
Regardless of the physical implementation of the Control 
Repository, all information is organized under the PFVL 
paradigm such that any entry in the repository directly or 
indirecdy maps to one or more PFVLs. This permits users to 
access information about any object residing in any. Package 
or library, at any Level or Variance regardless of whether 
that piece of information exists in a relationaLdatabase, a 
simple ASCII file or a binary encoded MctaData file. Infor- 
mation can be freely reorganized or transplanted between 
different Control Repository implementations without the 
need to modify any DMS AppUcations, Manager functions 
or Control Repository Access transactions. Tables support 
underlying Manager functions and DMS ApplicafioEDgT 

A key player in enabling the aforementioned feature are 
the COMMAND TRANSLATORS (26) which interface 
between the CONTROL REPOSITORY ACCESS LAYER 
and the CONTROL REPOSITORY (27). Each physical 
implementation of the Control Repository would employ a 
unique Command Translator to map the generic Control 
Repository Access transaction into the appropriate com- 
mand to satisfy the physical repository. For example, a 
relational database may be able to accept the Control 
Repository Access transaction "as is" or with a simple 
syntax modification while a binary encoded MetaData file 
would require a function capable of parsing and manipulat- 
ing the MetaData file. 

In a similar manner to the Data Repository, this approach 
also enables a great deal of flexibihty in upgrading the 
Control Repositories or permitting data from disparate 
sources to appear as one logical repository. For example, a 
SOL database may be employed as the primary Control 
Repository which includes all information necessary to track 
each object in the DMS by File Reference, PFVL, physical 
location, etc. This repository may also contain a Part Num- 
ber table for all the manufactured pieces of a product. Off to 
the side might exist a Lotus Notes database containing 
service call or defect repair information organized by Part 
Number for the same product. Our invention would allow 
Control Repository Access transactions to be written, using 
an identical SQL-like syntax, to extract design information 
about the part from the SQL database and repair actions 
from the Lotus Note database. This way someone with no 
knowledge of the underlying Control Repository structure 
could write a DMS Application to invoke said functions and 
create a customized report containing information from both 
databases. The Command Translators would be responsible 
for mapping the generic transaction for the design informa- 
tion into a true SQL command, and mapping the repair 
action transaction into a Notes transaction. 

DMS APPUCATION LAYER 

Our invention contemplates an architectural layer dedi- 
cated to the various DMS Functions and Utilities that a user 
invokes to manipulate the Data Management System. Com- 
mon functions found in this layer include, but aren*t limited 
to, Check-In, Check-Out, Promote, Setting Locks, Checking 
Authorities, etc. Furthermore, these functions share a con- 
sistent application program interface (API) following the 
PFVL paradigm, which allows this layer to remain method- 
ology and environment independent. 

FIG. 5 conveys the preferred embodiment of this layer. 
The DMS Applications Layer (51) is comprised of all the 
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appHcations that enable a user to interact directly with the 
DMS. Each application consists of one or more application 
modules (52) which may or may not interact with the various 
Managers (54). FIG. 5 depicts various scenarios involving 
the interaction with the apphcation modules: 
NON-MANAGER INTERACTION (55) An application 
may desire to interface directly to the Control Reposi- 
tory (56) without the need to interact with any Man- 
agers. An example might be a function which extracts 
project management data from the Control Repository 
and displays it in a formatted report. 
SINGLE MANAGER INTERACTION (57) An applica- 
tion may only need to interface with a single Manager 
in order to execute all the steps in the application's 
algorithm. For example, an application which associ- 
ates an object to a problem fix number only requires 
functions within the Problem Fix/EC/PN Manager. 
MULTIPLE MANAGER INTERACTION (58) Often 
application algorithms require interaction with a plu- 
rality of Managers. For instance, a promotion algorithm 
may interface with the Authority Manager to determine 
if the user has the proper promote authorization. Next, 
it may execute Process Manager functions to determine 
if the object meets the necessary promotion criteria. 
Finally, it may interface with the Library Manager to 
perform the actual promotion to the next level. 
CONTROL REPOSITORY COUPLED WITH MAN- 
AGER INTERACTION (59) Any combination of the 
above methods may be used to construct an application 
which interacts with one or more Managers in addition 
to the Control Repository. For instance, an application 
may query the Control Repository to see which Man- 
agers are currently installed in a user environment, and 
use that information to branch through various parts of 
the algorithm which interface with the Managers. 
Within each Manager, FIG. 5 depicts one or more Man- 
ager Functions (53) which combine to form a library of 
utilities upon which appfications can be constructed. For 
example, the Problem Fix/EC/PN Manager contains: 
Functions to associate objects to Problem numbers 
Functions to associate Problem numbers to releases 
Functions to associate Part Numbers to objects 
Together these modules form a library of fimctions within 
each Manager, upon which application developers can create 
more complex utilities. 

FIG. 5 also depicts an Application Program Interface (50) 
common to all applications and functions in the DMS 
Application Layer. The API is based on the PFVL paradigm. 
By requiring all the functions to conform to the PFVL 
paradigm they remain methodology independent while 
retaining the flexibility to be adapted to any user environ- 
ment through the use of the User Interface Layer, Our 
preferred embodiment requires aU functions in this layer to 
be invoked by passing PACKAGE, FILE TYPE, 
VARIANCE, and LEVEL as the minimum amount of infor- 
mation. Additional information such as filename, iteration, 
or run -time options may also be supplied. Our embodiment 
also permits the wild card character (*) to be used on any 
combination of PFVL attributes. For instance, if a wild card 
is passed in place of the LEVEL, then all information 
matching the remaining PFVL attributes at all levels is 
accessible. The wild card can be combined with a partial 
PFVL attribute in a similar .manner. In this case, a level 
attribute of PROD* would access all information matching 
the remaining PFVLs at any level beginning with PROD. 
Finally, a placeholder such as the percent (%) character can 
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be used to ignore any attribute. Certain DMS applications 
may not require information regarding all the PFVL 
attributes, so use of the % character allows every DMS 
application to use an identical API to facilitate interaction 
with the user environment. For example, the following API 
could be used to interface with all DMS applications regard- 
less of their underlying function: 

DMS_App_ 

Name<filename><filetype><package><varianc6>< 
level><options> 

If a user environment doesn't necessitate the use of all the 
PFVL attributes, the user interface layer can suppress or 
hard -code them prior to invoking the underlying DMS 
application. For example, a user environment may exist such 
that variances aren't applicable and data only resides in two 
levels of a single package (library). Furthermore, the current 
process only permits users to check data into the DMS at the 
lowest level. The corresponding user interface may be a 
simple menu where the only two fields the user enters are the 
file name and file type. The underlying user interface code 
would automatically pass the sole package and level, and 
hard-code or suppress the variance to the DMS check-in 
API. The advantage to the present invention is in the event 
the process changes to allow users to perform additional 
actions, such as checking data into the second level, only the 
user interface needs to be updated. Neither the underlying 
DMS applications nor the information in the Control 
Repository need to be updated. 

CLIENT/SERVER INTERFACE 

The present invention contemplates the use of a CLIENT/ 
SERVER INTERFACE embedded between the DMS Appli- 
cation and Control Repository Access layers. All commu- 
nication between the DMS applications and the Control 
Repository functions is performed through special interface 
routines. These routines are responsible for locating the 
proper Control Repository, making the connection, and 
passing the appropriate information to the underlying Con- 
trol Repository Access function. This feature allows a com- 
pletely scalable DMS ranging from a low-end DMS where 
the Control Repository is directly accessible from the user's 
client to a high-end enterprise DMS where the Control 
Repository can be literally spread across a plurality of 
worldwide servers. For the low-end implementation, the 
client/server routines simply pass the required information 
from the DMS application to the CR Access function, much 
like a parent module invoking an external function or 
subroutine. In the high -end scenario, the routine would 
locate the server where the appropriate CR resides, make the 
appropriate connection and pass the information to the CR 
function. 

In addition to controlling the interface between the DMS 
applications and Control Repository, the client/server inter- 
face also controls access to the Data Repository. Once again, 
a low-end system may exist whereby the data resides in a file 
system directly updatable by the user's client. For example, 
during a Check-In process, the client would physically copy 
the data firom the source location to the actual data reposi- 
tory. This could be accomplished by providing write access 
to the data repository for all users, or writing a client/server 
routine which utilizes techniques such as Unix SETUID bits 
to ensure that data can only be written to the repository via 
the proper DMS applications. In the high -end scenario, the 
client/server routines could establish a coimection with the 
server where the data repository resides and employ the 
server to perform the appropriate file operation. This imple- 
mentation lends itself to a more secure DMS since access to 
the data repository can be very tightly controlled, and user 



clients can not directly update the data repository outside of 
the DMS either intentionally or accidentally. 

Referring to FIG. 2, the DMS applications(22) and the 
Various Managers(21) as well as the Control Repository 

5 Interface(24) all communicate with the Data Repository(25) 
and the Control Repository(27) via the Client/Server 
Interface(23). This interface is depicted in FIG. 7, where the 
DMS applications, the various Mangers and the CR inter- 
face layer is shown (71). Depending on the location of the 

10 server, i.e. local or remote, the respective Communications 
Services(72) are invoked. These services support a variety of 
protocols including but not limited to those depicted in the 
(73) layer. Some of these services communicated either 
directly to the Data Servers(75), through the network and or 

15 the severs depicted at the (74)1 ayer. 

As an alternate embodiment for this layer, AUTOMATED 
LIBRARY MACHINES (ALM) are employed in a "batch" 
environment which permits a large number of DMS opera- 
tions to be queued and processed by these virtual machines. 

20 The Client/Server routines are responsible for creating work 
requests on the user's client and transmitting them to the 
appropriate ALM for processing. Use of ALMs also pro- 
vides the advantage of breaking up large complex DMS 
applications into foreground and background pieces. The 

25 foreground portion runs on the user's client, then a work 
request is created and transmitted to the ALM through the 
Client/Server Interface. Upon receipt of the work request, 
the ALM processes the background portion of the DMS 
operation, including all file manipulations. Since the fore- 

30 ground portion tends to comprise a series of checks as 
opposed to intensive computing, improved client throughput 
can be achieved by offloading the more compute intensive 
portions of the DMS application to the ALM. 

CONTROL REPOSITORY ACCESS LAYER 

Our invention contemplates the use of a separate Control 
Repository Access Layer comprised of a library of functions 
or TRANSACTIONS which extract, add, modify or delete 
information from the Control Repository. There are two 
main advantages to separating this code from the functions 
comprising the DMS Application Layer: 

1. Many transactions can be used in multiple DMS 
applications, so in an effort to modularize the code and 
prevent duplication, one skilled in the art could envi- 
sion how these transactions can be instantiated in DMS 
applications much like a logic designer instantiates 
circuit macros. 

2. In larger DM systems where performance is a critical 
issue, it is frequently prudent to combine several 
smaller transactions into "macro" transactions, lliis is 
best performed by someone with intimate knowledge of 
the internal organization of the Control Repository. By 
separating the CR Access functions from the DMS 
applications, the end users can readily modify the DMS 

55 applications without acquiring the aforementioned 
knowledge. 

An illustration of the above principles can be made using 
a translation from an API call down through multiple 
managers to the command translators. 

60 Assume that "usera" wishes to set a "move'* lock on 
"filel.type2.varx" at the "entry" level for the purpose of 
"MODEL BUILD". The user would invoke the API call 
"SetLock move filel type2 varx entry "MODEL BUILD"". 
Referring to FIG. 8, the API call is represented(81). The state 

65 table(82) is used to convert the API call into invocations of 
the Authority Manager File Authority Check(83) and the 
Lock Manager SetLock (84) routines. 
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FIG. 9 depicts the Control Repository Interface (CRI) care. Fortunately, most of the data found in said environment 

call(91) employed by the Authority Manager to perform the can exist in electronic format capable of being stored on a 

File Authority Check. This in generates the SQL transaction computer system. Typically this data emanates from a vari- 

(92). In addition, FIG. 9a depicts the CRI call(93) employed ety of disparate sources and is stored in a multitude of 

by the Lock Manager to perform the lock set. This generates 5 formats. Our invention enables all of this data to be auto- 

a sequence of three SQL transactions(95). It should be noted matically transmitted to a central DMS and organized using 

that all CRI calls arc atomic, i.e. All SQL transactions in a the PFVL paradigm. This allows the data to reside in a 

CRI call must complete successfully. If one transaction fails, plurahty of storage media and permits the flexibility of 

all previously completed transactions are backed out. either importing all the data into a single physical repository 

COMMAND TRANSUVTORS 10 '^^^ ^ relational database or dispense with the 

unport/export operation and track the data m its original 

Our preferred embodiment also depicts all Control location 

Repository Access functions to be written in a common p,Q lOA depicts how our invention can be used to apply 

genenc form, adhering to the fundamental concept that al ^^^^j ^ ^j^^ .^^^.^ ^ ^^^^^ ^,,^^5^^ 

Control Repository intormation is organized in virtual r .1 j -ir . j . t_ • . * . .1 a 

tables. This also holds true for transactbns that reference is ^^^^^f data objects into a central repository. A 

information residing in a Control Repository which is not ^^^^^^^ /^wx^i^^l "^"^ 

physically implemented using tables. The COMMAND ^^^^^^ ^uch as NEW ARRIVAL, ADMITTED, and 

TRANSLAI^ORS serve as the interface to the physical DISCHARGED. When the patient enters the hospital 

embodiments of the Control Repository. (whether it^s for a scheduled admission or the emergency 

An example of the above architectural principle is 20 room), a bracelet with a bar coded patient id is attached. The 
described herein. All CR Access functions are written as a Patient id number is the primary PFVL attribute. A bar code 
series of add, modify, delete or extract operations in a scanner (14) initiates a LIBRARY PROCESS (102) which 
SQL-based language that treats the information as if it were creates the patient's electronic chart (103) and checks it into 
stored in SQL tables. If the underlying Control Repository is the NEW ARRIVAL level. In addition, the UBRARY PRO- 
indeed a SQL database, the command translator passes the ^5 CESS opens the patient's bill with the date and time he 
transaction to the database with little or no modification. entered the hospital. The bar code scanner could be a 
However, if the information is organized in a flat file, the conventional scanner connected to a personal computer via 
command translator would map the virtual table to the a serial or SCSI interface. At this point, the personal corn- 
physical organization of the file. puter would execute a DMS application which would cap- 

FIG. 6 depicts a scenario where the virtual Control ture the bar code data stream and forward it to the DMS 

Repository is physically comprised of a SQL database (65) (101) as part of a Checkin Library Process. One can envision 

and an encrypted meta-data file (66). COMMAND TRANS- the DMS residing on a server and the personal computer 

LAim A (62) simply passes the generic SQL-based trans- interacting with it via a LAN, WAN, TCP/IP, modem, 

action (61) to the SQL database after a simple modification wireless or any other type of chent to server connection, 

into a tme SQL transaction (64). Conversely, transactions ^. *'a*u * 1* j ju j 

destined for the meta-data file are sent to COMMAND 35 Our invention further contemplates an advanced bar ^^^^ 

TRANSLATOR B (63). Inside this translator, the met-dala ^ ^^^f "^'^fy "^''^ ^^^^^ using one of 

file is parsed using the proper decryption technique to locate aforementioned protocols. In this aUernate embodiment, 

the data that maps to the generic Control Repository infor- T^tt ^ programmed with a 

mation contained in the transaction. In the case of an add or ^""P^^ application that transmit the patient ID mfor- 

modify operation, the new information is encrypted and 40 mation along with the necessary PFVL attnbutes. 

embedded in the appropriate position within the file. This P^^^^"^ ^ admitted, then at the time a room is 

architectural approach permits information residing in exist- assigned and transportation wheels him to his room, the 

ing meta-data, or non-DMS databases to be included as part ^^^^^^y ^^^^^ ^ ^^^^ ^^^^ ^s a pahntop (10) to allow 

of the centrahzed DMS Control Repository by simply writ- ^^^^^^y ^^^^r ^he mformation with the room number, 

ing a command translator to perform the mapping between 45 This would trigger a PROMOTE REQUEST (104) to the 

the generic (repository independent) transaction and the ADMITTED level. 

interface to the physical repository. Once again, LIBRARY PROCESSING takes care of 

Returning to FIG. 1, the present invention contemplates updating the bill to reflect the proper room charge. In 

the use of the modular, scalable architecture illustrated in addition, if the hospital is usmg a single database to manage 

FIG. 2 through FIG. 9 to construct the Central Repository ^0 everything, and the reception desk has access, then they can 

(18). The various pervasive computing and peripheral simply query the patient infonnation to direct visitors to the 

devices shown in FIG. 1 (10 through 17) contain DMS Patient's room. Otherwise, if they are usmg a separate 

Applications (22) which can range from very simple "hard- system, the promote could also tngger a Library Process to 

codetf' appUcations embedded in the RAM or ROM of a ^P^^^^ reception desk's system with the new patient's 

microcontroller or digital signal processor (DSP) to complex 55 room infonnation. 

user interface applications comprising graphical user inter- Throughout the patient's stay, several diagnostic tests 

faces (GUI), web browsers, etc. llie DMS Application (X-Ray, MRI, CT-Scan, etc.) (16) may be run. Upon 

running on the pervasive computing devices gather the completion, the results are stored electronically in a disk or 

appropriate PFVL information and launch a transaction. In '^pe file. In a simplistic scenario, a computer connected to 

the most common embodiment, the transaction is delivered ^i^k or tape file can execute a DMS application to 

to the Central Repository through the Chent/Server Interface perform a CHECKIN (106) of the test results (107) into the 

(23) via the communication services illustrated in FIG. 7. Admitted level. An alternate embodiment contemplates 

embedded controllers within the equipment which could 

^^^DDcccSoc^^^^'^^^^*^ ™^ execute small DMS applications to automatically classify 

PREFERRED EMBODIMENT ^^^^ ^^^^^^ ^^^^ PPYL ^nd promote it directly to the 

The present invention can be employed in a hospital ADMITTED level of the central repository on the server, 

environment to automate and facilitate all aspects of patient bypassing the need for the external disk or tape file. 
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A more sophisticated embodiment would employ a stor- left blank, the UNIT OR WARD field (110) is implemented 

age medium such as disk or recordable CD-ROM with with a drop-down menu to select the Package (Library). The 

sufficient file management capabilities to permit the PFVL STATUS field uses a drop-down menu to select the Level 

paradigm to be applied directly to the data while it resides and the SUBJECT MATTER field also uses a drop-down 

in the disk or tape file. For example, a directory structure can 5 menu to select the type of data. These fields directly map to 

be established using the Library, Level and Data Type as the PFVL attributes which drive the Library Search and the 

branches of the directory tree. Read-Only checkout. One skilled in the art can envision how 

In the case of a recordable CD-ROM, the directories could any of these fields can also allow a selection of ALL which 

serve as temporary levels or staging areas where the data resiilts in that PFVL being wild carded. For instance he 

resides until a convenient time for uploading to the central could request a read-only checkout of the patient's chart, 

server. In the case of a disk file, one could envision how the latest heart monitor results, and the images from yesterday's 

DMS architecture described in FIG. 2 can be used to adjoin cardiac catheterization. 

both the physical repository containing the patient's chart, The advantages of the present invention are numerous, 

billing data, doctor's reports, etc. with the medical image Since the PFVL paradigm acts as the "glue" to hold every- 

results residing in the disk file. At this point the images have thing together, each device only needs to know how to work 

been electronically stored in the same central repository as with it's own type of data. Assume that DB2 is chosen as the 

the patient's other medical data, and can be retrieved in a main repository, the remote devices such as the MRI 

consistent manner. In addition, daily diagnostic data such as machines, heart monitors and palmtops don't need to run a 

heart monitoring and blood test results can also be uplinked copy of DB2 or understand SQL. They simply need a means 

and checked into (106) the central repository either directly for connecting to the server and transmitting a simple check 

using embedded controllers in the equipment or by portable in request along with the data they are uplinking. One only 

computing devices carried by lab technicians. needs to write a small embedded application program to 

Every time a doctor or nurse needs to update the patient's create the check in request and upload the data. If the 

chart, they do it electronically using one of several means, underlying DB2 database changes next year or is replaced 

depending on the amount and content of information they 25 Oracle database, it doesn't affect the remote devices, 

must enter. For example, someone simply taking vital signs Furthermore, the central repository can be distributed 

could use a hand-held device such as a palmtop, whereas a across multiple systems or contained within a single system, 

nurse may sit down at a PC or laptop during change of shift In some cases a large system such as the latest release of 

to type up chart notes. Regardless of the device used, the DB2/Universal running on an S/390 could possibly manage 

action is the same. A CHECKOUT (105) is performed to 30 all the necessary types of data (patient's chart, test results, 

ensure the chart is locked out and nobody else can edit it images, billing, etc.). However, there may also be situations 

simultaneously. In the first case, the palmtop simply appends where the repository is distributed throughout a cluster of 

the vital signs with timestamp information to the chart. In servers, perhaps running a combination of Windows NT, 

the second case, the nurse's notes are also appended, but the Unix and S/390. Some of the data may reside in a true 

nurse would also have access to the entire chart. In either 35 database, while the remainder may simply exist as files in 

event, once the new information is entered, a CHECKIN directories. Our invention works independently of the plat- 

(105) stores the chart back into the ADMITTED level and form so one can envision the entire repository consisting of 

release the lock. If necessary, revision control can also be file servers, databases, personal computers (workstations), 

used to create a history trail of updates. palmtops, laptops, web servers, storage media attached to 

FIG. lOB shows the DMS (101) expanded to include a 40 Although this invention was illustrated using a hospital 

DISCHARGED level. Once the doctor authorizes the example, one can envision the same concepts being applied 

patient's release by updating the electronic chart (103) using to other areas such as a manufacturing environment. Con- 

apersonalcomputer(15),laptopor workstation, a chent side sider the following company which exemplifies a typical 

DMS application initiates a promote request (104). The manufacturing scenario. Raw materials or parts are procured 

patient id and level name are the only required PFVL 45 from suppliers and received into inventory. Often these 

attributes, whereas the type is wild carded. This results in all materials or parts need to be inspected for quality assurance, 

the data associated with that patient's hospital stay being These parts and materials are then made available to both 

promoted to the DISCHARGED level. Library processing engineering and manufacturing. During assembly they are 

triggers the final bill to be tallied and sent to the patient. Any incorporated into finished products which must be shipped 

questions or disputes about the bill can be quickly handled 50 and distributed. 

because all of this data is accessible by a common means. FIG. IIA illustrates such a manufacturing environment 
The advantages of our invention continue after the patient consisting of a multi-leveled Central Repository (18) com- 
isdischarged.Adoctor, at any lime, either in residence at the prised of a RECEIVING level, a QUALITY CONTROL 
hospital, or working remotely, can access whatever data he level, an INVENTORY level, and a REJECT level. Our 
needs. FIG. lOB illustrates a server (12) which could be used 55 invention demonstrates how the parts and raw materials can 
to initiate a LIBRARY SEARCH OR READ-ONLY be entered into a centralized data management system upon 
CHECKOUT to access the patient's data. If the doctor is a arrival at the receiving dock. Bar code scanners or similar 
resident of the hospital where the patient stayed, then the portable devices (14) could be utilized by loading dock 
server (12) could be attached to the same network as the employees to classify the parts and materials by PFVL and 
DMS. However, the doctor may also have a laptop or PC at 60 execute a small Library Process (102) to create an electronic 
home or the doctor may not be afi&Iiated with that hospital. invoice (201) in the RECEIVING level. When it comes time 
In this case the server (12) could be a web server or remotely to inspect the parts for quality assurance, the parts are 
accessible server, which would permit the same access using transported to the QA area. At that time a hand-held corn- 
applicable security methods. FIG. IOC depicts an entry puter (10) such as a palmtop can be used to promote (104) 
screen which could be an independent DMS application or 65 the invoice to the QUALITY CONTROL level. Our inven- 
implementcd with HTML or Java for use over the world tion even contemplates an automated transportation system 
wide web. The PATIENT ID field (109) can be filled in or whereby the transportation equipment itself could initiate 
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the promote request upon delivery of the items to the Quality 
Assurance area. 
As the QA inspectors pass or reject the raw materials, they 
^\^caii enter their results into palmtops, laptops or similar 
devices. Goods that fail QAcan be promoted into a REJECT 
level where several actions may be triggered via Library 
Processing, For example, the carrier (i.e. UPS) could be 
automatically notified (202) to come and pick up the defec- 
tive parts for return to the supplier. Additionally, a fax or 
e-mail could be automatically sent to the supplier informing 
them of the pending parts return and requesting replacement 
parts or credit. The parts that pass QAcan are promoted into 
the INVENTORY level where an UPDATE QUANTITY 
(203) Library Process can update the Control Repository 
(18) with the new quantity of parts now available in INVEN- 
TORY. Further benefits are derived from the PFVL paradigm | 
because the INVENTORY level can also contain additional J 
information beyond that pertinent to the parts just received. [ 
For instance general information such as design / 
specifications, data sheets, pri ce & sales data, drawings, 
images, etc. can alTcoexist at tEis level. These'oUjects may 
exist as HyperText Markup Language (HTML) files. Por- 
table Document Format (.pdf) files, graphics files in JPEG, 
AutoCad, Bitmap or other forms, or information stored as 
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fields in a database. Regardless of its location, application of \ 



the PFVL paradigm permits uniform access to all of the data. 

Our invention further contemplates how engineers can 
reference information about the parts and raw materials from 
the INVENTORY level to create the drawings and specifi- 
cations for their company's products. During manufacturing 
of the products, a robotic assembly line (11) procures the 
parts from inventory. As they do, embedded controllers in 
these robots initiate transactions which update the inventory 
quantities as the parts and raw materials are depleted. In 
addition, CONFIGURATION MANAGEMENT allows the 
embedded controllers to spawn transactions which UPDATE 
THE BILL-OF-MATERIALS (204) for the product under- 
going assembly. When the product is completed, a corre- 
sponding hierarchical Bill-of-Materials will exist which 
shows every subsystem in the product, and every vendor part 
in each subsystem. FIG. IIB shows one such Bill of Material 
list (205) indicating five components whereby three of them 
are from various RELEASE levels of the DESIGN Library, 
and two of them are from the INVENTORY level of the 
PARTS Library. It should be noted that the modular Data 
Management System described in FIG. 2 permits a plurality 
of storage engines to comprise a single Central Repository. 
'ITiis is illustrated by the fact that components in the 
DESIGN Library have revision control numbers applied 
while components from the PARTS Library uses simple 
reference numbers for tracking. 

One benefit of practicing these data management methods 
is this information can be analyzed using data mining 
software to predict the effect of future changes such as a 
price increase of a frequently used vendor component. The 
company would be able to ascertain exactly which and how 
many of their products use a particular component, obtain 
sales data, and decide whether the products have enough 
profit margin to absorb the price increase, whether the 
increase needs to be passed on to the consumer or whether 
a replacement vendor component needs to be found. 

These same principles can be further appHed to finished 
products which require distribution and shipping. As the 
products complete assembly, they can be promoted into an 
IN STOCK level similar to the INVENTORY level in FIG. 
11 A. Several actions can occur depending on the type of 
company. If it's a mail-order house, telephone sales agents 
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can perform LIBRARY SEARCHES for products at the IN 
STOCK level to determine whether the product is available 
for shipment to the customer. When the customer places an 
order, the product could be promoted to a SHIPPED level 
which triggers LIBRARY PROCESSES to initiate the ship- 
ment of the product (i.e. arrange for transportation of the 
product to the shipping area, contact Federal Express for 
pick-up, etc.), and generate an invoice to be billed to the 
customer. In cases where the finished products are shipped 
directly to retailers, promotion to this SHIPPED level can 
enable a transaction to be sent to the retailers' Data Man- 
agement System to inform them that the arrival of new 
products are pending. Our invention contemplates the use of 
the PFVL paradigm as the basis for the retailers' Data 
Management system such that the two systems can work in 
conjunction to track the products. This is just one example 
of how potentially disparate systems between a supplier and 
customer can be linked to form a tightly coupled e-business 
relationship. 

Turning our attention to a different scenario involving 
remote and mobile computing, the present invention offers 
several methods for improvement. For instance, applying the 
PFVL paradigm to the data stored in a Notes database 
permits library searches to retrieve desired data and filter out 
unwanted data. FIG. 12 A illustrates a replication scenario 
involving an attorney using Notes with our invention 
applied. The PFVL paradigm is used to categorize the data 
objects stored in the Notes database by type. The Notes 
database serves as the PACKAGE (301) (or Library) having 
multiple LEVELS (302) such as WORK IN PROGRESS, 
1997 COMPLETED CASES, and 1998 COMPLETED 
CASES. 

The attorney's data is organized into Notes FOLDERS 
(303) such as INSURANCE FRAUD, LEVERAGED BUY- 
OUTS and REAL ESTATE. The attorney has a personal 
computer (15) in his office which is his primary client. When 
the attorney wants to work on a case at home on his laptop 
(17), he can perform a replication comprising a LIBRARY 
SEARCH (304) of all of his WORK IN PROGRESS for all 
existing folders. Our invention also contemplates the con- 
tinued ability to selectively include or exclude folders from 
replication to further restrict the repUcation to work in 
progress for a specific folder. On the other hand, if he only 
needs to reference a completed case, he can start his search 
at 1998 COMPLETED CASES without the need to replicate 
all of his WORK IN PROGRESS. 

Furthermore, since the PFVL paradigm is independent of 
the underlying storage engine, it can be applied to the data 
inside and outside of Notes. For example, the attorney may 
have a case comprising documentation in many different 
forms. There may be numerous memos, e-mail and Notes 
documents stored within Notes' folders, but there may also 
be attachments such as WordPro documents that were 
detached and stored in a directory structure outside of Notes 
(i.e. C:\LOTUS\WORK\WORDPRO). There may even be 
data such as bitmaps derived from scanned paper documents 
or images generated by digital cameras, which are part of the 
case, but not necessarily part of the Notes database. Regard- 
less of where these objects are physically stored, the Notes 
database can still be used as a Control Repository to manage 
the PFVLs associated with these objects. Hence the Word- 
Pro document and scanned bitmap image can still be attrib- 
uted with the same case identifier and level (i.e. WORK IN 
PROGRESS) as the real Lotus Notes data. This permits 
replication to use the PFVL to search for and extract any 
type of data the attorney needs regardless of its physical 
location. Replication can further be enhanced to permit the 
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data to be filtered by type, once again preventing unwanted 
data (such as sizable bitmaps) from being replicated. 

FIG. 12B illustrates this concept in greater detail. The 
central repository exists on the SERVER (310), which is 
comprised of a CONFTROL REPOSITORY DATABASE 
(311), a CHECK IN OUT DATABASE (313) and a DATA 
REPOSITORY (312) which could exist on the same server 
as a central repository or on a separate data server. The 
user's remote Workstation (314) contains a WORKSPACE 
DATABASE (316), storage space for any external data 
(317), and an optional READ ONLY CONTROL REPOSI- 
TORY (315). 

To access or modify a data object(s), the xiser selects the 
object(s) from either the Server (310) or the local replica 
copy of the Control Repository (311) and invokes the 
CHECK OUT DMS application. In the case of Lotus Notes, 
this application can be implemented as an AGENT. The 
AGENT will mail a CHECK OUT request to the Check In 
Out Database (313) which checks for existing Lock docu- 
ments. If there are none, an OUT FOR UPDATE Lock 
document is created to prevent duplicate checkout. Finally, 
a copy of the selected data object(s) is mailed to the 
Workspace Database (316). 

Upon completing modifications of a checked out object, 
or upon creation of a new object, the user initiates a CHECK 
IN action which mails a copy of the object(s) to the Check 
In Out Database (313). For any objects residing outside of 
the Workspace (316) in the local storage space (317), the 
CHECK IN DMS application would also attach the files to 
a document contained within the database. For example, an 
attorney's brief might be a document residing within the 
Workspace Database while images created by a digital 
camera may reside on a local hard drive. Upon receipt of the 
mailed copy, the Check In Out Database (313) runs the 
CHECK IN DMS application which is implemented as a 
Lotus AGENT. This agent creates a document representing 
the attorney's brief in the Control Repository (311) at the 
WORK IN PROGRESS level, and detaches any external 
files (such as images) into the Data Repository (312). Files 
in the Data Repository (312) are tracked using pointers in the 
Control Repository (311) documents. Furthermore, 
AGENTS can also execute Library Processing to perform 
automated tasks such as data translation or checking. 
Additionally, the Check In Out Database (313) serves as an 
Automated Library Machine (ALM) and our invention con- 
templates a plurality of these ALMs serving users of large 
data management systems. 

FIG. 12C depicts how the Package, FiieType, Variance 
Level, and Version attributes are mapped into the Lotus 
Notes environment using databases, docii merits and docu- 
me nt fields. Although the aforementioned example uses 
Lotus Notes to illustrate the principles contained herein, one 
skilled in the art can appreciate how these concepts along 
with other concepts such as Configuration Management, 
Part Number and Release Management, FixJIJ^cking,_and 
Library Processing can be further implemented usingXotus 
Notes_o£5n^5DiltiSS2tex^ 

emplo>dngameansof£mbodyi a program^finstnictiohs. 
One can also appreciate how these concepts can be realized 50 
in simpler applications such as spreadsheets which provide 
the capability to enter data tabular format and perform sort 
and search operations on the fields. ^ 

In addition to the PFVL paradigm, various aspects of the 
S.O.M,A. architecture can be employed within applications 65 
such as Lotus to improve mobile computing. Presently, 
replication assumes the user wants the data to permanently 
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reside on the client. This assumption is probably valid for 
WORK IN PROGRESS data since the user desires to keep 
this data in sync between a plurality of computers (i.e. home 
and office) so the data can be locally accessed from either 
location. On the other hand, if data only needs to be 
referenced on a temporary basis, such as data residing in the 
1997 COMPLETED CASES level, our invention provides a 
means to reclaim the storage space on the client device. 

The present invention demonstrates such means whereby 
replication employs the concepts governing check-outs, 
promotion, and private libraries to permit different actions 
on the client side. For instance, work in progress would be 
checked out such that if the attorney makes any edits, the 
data would be flagged for pending "promotion" back into the 
work in progress level during the next replication. ITiis way 
the edits materialize back into the server and will be propa- 
gated to other clients in future replications. On the other 
hand, the referenced data from the 1997 completed cases 
could be checked out read-only. Data flagged in this manner 
can be safely deleted from the client without a correspond- 
ing delete action occurring on the server. One skilled in the 
art could see how replication could be further improved to 
ask the user to enter an expiration date for read-only 
checkouts such that the data is automatically expunged from 
the cHent after the elapsed time. 

The advantages offered by the our invention are presented 
by way of a further comparison with the current art. One can 
envision how the aforementioned level structure can be 
beneficial as PROMOTION can be applied to allow data to 
traverse through different phases of a project or program and 
eventually retire in a final resting place. In the above 
example, once a case is finished, all the data associated with 
that case would be promoted into one of the COMPLETED 
levels. Although, one could attempt to mimic this using 
folders in the present art, it would be awkward. For instance, 
if the attorney has cases "in progress" for insurance fraud, 
leveraged buy-outs and a real estate deal, he would either 
have to combine all the cases into one folder labeled WORK 
IN PROGRESS or create three folders labeled INSUR- 
ANCE FRAUD WORK IN PROGRESS, BUY-OUTS 
WORK IN PROGRESS and REAL ESTATE WORK IN 
PROGRESS, If the user wants to replicate all of his work in 
progress he must remember to select all three folders for 
replication. The problem increases if multiple users want to 
share the same data. 

The present invention would execute a replication method 
utilizing the CHECK IN/OUT DATABASE depicted in FIG, 
12B. The user would be able to control the amount of data 
replicated by using a combination of PFVL attributes 
(Package, Level, Type) and folders. This improvement on 
the present art permits the user to eflSciently access, for 
example, all 'Svork in progress" or only a subset of those 
cases. If the user desires read-only access, the data can be 
checked out and flagged for deletion. On the other hand, if 
the user intends to update the data, a full checkout can be 
performed which enables the LOCK MANAGER shown in 
FIG. 2 to establish ownership for the data and prevent other 
users from making simultaneous updates. 

The application of our invention to the remote computing 
environment introduces new opportunities for pervasive 
devices. The remote device can execute a small DMS 
application to initiate a connection to the Notes server and 
query the type of data it*s designed to process. For example, 
very simple devices such as PDAs or electronic organizers 
could perform a checkout of e-mail or to-do lists. In very 
low-end devices with limited data entry capability, the user 
would checkout the data in a read-only fashion just to 
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browse information. The higher end devices such as given package can contain any combination of data objects 

palmtops, which permit data creation and editing, would and/or packages. 

contain a slightly more sophisticated DM application which 4. The method according to claim 1 wherein said data 

permits checkout-for-edit and promotion of the updated data management system comprises a plurality of data managers 

back to the Notes server. 5 arc configurable and can be dynamically or statically com- 

Non<omputer devices such as pagers, cell phones, digital bined as modules of a scalable system ranging up to a 

cameras, music and video equipment could also interact high-end enterprise wide DMS. 

with the Notes server in a similar fashion. For example, a 5. The method according to claim 1 wherein is provided 

pager or cell phone could connect to the Notes database and a User Interface Layer for interaction with said pervasive 

query a phone number from the address book. A digital computing devices via said API which enables mapping of 

camera could promote its photos into the repository. A midi a methodology, process, use-model or environment into a 

keyboard could checkout midi files from a music library generic PFVL paradigm using tools which can be manipu- 

residing in a Notes database. A pocket tape recorder using an lated by said user, including industrial robots, palmtop 

embedded version of IBM ViaVoice could permit the user to computers, bar code scanners, medical diagnostic 

dictate a memo and then promote the resulting document equipment, cellular telephones, pagers, digital cameras, 

mto the repository. electronic organizers, laptop computers, audio/video dicta- 

Our invention offers the advantage that a remote device tion and recording devices, menus, GUIs, and Web Brows- 
doesn't need to run the same application being used to 

implement the repositoiy (Notes, SQL, Oracle, etc.). The ^ -^he method according to claim 1 wherein is provided 

device contains a very simple embedded appUcation pro- ^i,^ ^nc or more DMS application layers which contains 

gram which establishes a connecUon to the repository, 20 utilities that a pervasive computing device requires to inter- 

mitiates quenes, checkouts, promotes, etc. and processes the ^^^^ promotion, check-in, check- 

data, rhese functions can easily be accomplished using an . , i • , i_ u- ... \ - - 

embedded controller, DSP or specialty ASIC. Because the out, lockmg, library searching, setting and viewing process 

hardware requirements are so paltry, virtually any remote '^^f^^ aggregations, and managmg parts, releases 

device can participate. 25 ^""^ ^'""^^^"^ ^ 

While we have described our preferred embodiments of ^^^^ according to claim 6 wherein said DMS 
our invention, it will be understood that those skiUed in the apphcation layers contam apphcations, each of which is 
art, both now and in the future, may make various improve- composed of one or more application modules which inter- 
ments and enhancements which fall within the scope of the ^^^^ ^^^^ ^^^^ managers in one or more ways of mterac- 
claims which follow. These claims should be construed to 30 including: 
maintain the proper protection for the invention first dis- non-manager interaction; 
closed. single manager interaction; 

What is claimed is: multiple manager interaction; and 

1. A method for enabling a central data management control repository access coupled with manager interac- 
system to interact with a pervasive computing device, com- 35 tion. 

prising the steps of providing a common access protocol for 8. The method according to claim 7 wherein said DMS 

enabling any pervasive computing device capable of execut- applications and data manager functions can be accessed by 

ing a control program tangibly embodying a program of pervasive computing devices using a common API based on 

instructions to interact with a centrahzed data management the PFVL paradigm whereby all functions require a mini- 

system, and providing a commonly accessible data manage- 40 mum of Package, Filetype, Variance, and Level but may 

ment system which possesses a plurality of data managers permit additional optional parameters, and any combination 

for data residing in a data repository managed by a virtual of wild cards or placeholder characters may be used on any 

control repository, wherein said data management system of the parameters. 

possesses a plurality of data managers, and the method 9. The method according to claim 1 wherein data is stored 

further comprises the steps of 45 in one or more data repositories constructed with one or 

providing said plurality of data managers in one or more more tools including simple directory trees, commercially 

layers of a layered architecture, and perfonming with a available PDMs (storage engines), and the WWW and each 

data manager and with a user input via an API a repository may employ a common or unique storage and 

plurality of processes on data residing in heterogeneous data access method. 

data repositories of computer system including so 10. 'ilie method according to claim 9 wherein each data 

promotion, check-in, check-out, locking, library object is classified by PFVL and unique File Reference 

searching, setting and viewing process results, tracking regardless of the physical data repository in which the data 

aggregations, and managing parts, releases and prob- object resides. 

lem fix data under management control of a virtual 11. The method according to claim 9 wherein one or more 

control repository having one or more physical hetero- 55 of said data repositories resides completely or partially 

geneous repositories, and storing, accessing, tracking within the pervasive computing device, 

data residing in one or more said data repositories 12. The method according to claim 1 wherein said virtual 

managed by said virtual control repository. control repository's physical repositories consist of reposi- 

2. The method according to claim 1 wherein any type of tories selected from the group of: relational databases, object 
data generated, captured, manipulated or otherwise trans- 60 oriented databases, flat files, table formatted files, Lotus 
mitted by said pervasive computer devices can be mapped Notes databases, any application capable of handling data in 
into a package, Filetype, variance and a PFVL Level tabular format such as spreadsheets, meta data files and 
whereby within a variance there exists one or more data proprietarily formatted files and said Control Repository 
objects of a given type residing at one or more levels with classifies all data according to the PFVL paradigm. 

one or more versions. 65 13. The method according to claim 1 further comprising 

3. The method according to claim 2 wherein packages are a scalable client/server interface permitting the DMS to use 
hierarchical and contain other Packages, and wherein a local services to run in a client-only mode on the pervasive 
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computing device and permitting a combination of local & 
remote services to run in a fully secure distributed client/ 
server mode. 

14. The method according to claim 1 wherein command 
translators are employed to map generic SQL-based virtual 
control repository transactions into any required command 
interface needed to interact with the corresponding physical 
implementation of said virtual control repository. 

15. The method according to claim 1 wherein said per- 
vasive computing devices communicate with said data man- 
agement system using a variety of protocols such as TCP/IP, 
token ring, ethernet, Bisync, RS-232, HITP, DCE, wireless, 
infrared, optical or any protocol capable of establishing a 
connection between a multitude of computing machines and 
transferring digital data streams. 
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16. The method according to claim 1 wherein disparate 
pervasive devices interact with a plurality of data manage- 
ment systems to exchange data in an e-business environ- 
ment. 

2 17. The method according to claim 1 wherein remote 
computing devices employ the PFVL paradigm to perform 
synchronization of data between a centralized data manage- 
ment system residing on a host system and localized replicas 
residing on one or more remote computing devices. 
18. The method according to claim 17 wherein pervasive 

10 computing devices with limited data entry, storage, I/O, or 
memory capabilities can participate along with traditional 
remote computing devices such as laptop or notebook com- 
puters in a synchronization or replication environment. 

9|e 4c 4: * 3|e 
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